DSO Function Authentication

TOP | Up | Pheedbak | Download | Tree | Topic | A-Z | Search | Hot | New

DSOauth is an example of how to protect DSO function calls from being intercepted or replaced. There are several mechanisms that can be used at link time that prevent this kind of substitution but they all have drawbacks. Options like -exact_version, -no_library_replacement, and creating a non-shared application with the option -non_shared can all keep functions from being replaced but they all do this at the expense of all the extremely desirable features of DSOs such as the ability to update DSO libraries without recompiling or relinking the application.

An application or licensing code developer can use DSOauth in their application such that they can protect their DSO function calls from being intercepted or replaced (eg. preventing substitution of the gettimeofday call in a license verification routine) without giving up any of the features of DSOs.

The most basic secure approach to making sure you are using the exact routines from exactly the right DSO is to use dlopen with the absolute pathname of the DSO you are interested in (eg. "/usr/lib/libc.so") and then using dlsym to get the address of the routine you are interested in. However, because dlopen and dlsym are themselves within a DSO they are also susceptible to replacement.

That's where this sample code comes into play. Since dlopen and dlsym are the basis of verifying the address of routines in DSOs, we must ensure that dlopen and dlsym are themselves the exact functions from /usr/lib/libc.so. By using the libelf routines (/usr/lib/libelf.a, a static library) we determine the vaddr and size of where the libc DSO is going to be loaded. Then we compare the addresses of dlopen and dlsym with the range of vaddr->vaddr+size. If it is out of that range we know that dlsym is being replaced.

To test this out first run smartapp by itself

% smartapp

This sample app uses the DSOauth routine and reports back that dlsym is the right one.

Using "subversion", an app which shows a very straightforward method of replacing a function within another DSO,

% subversion smartapp

we see that the program was able to detect the incorrect address of the dlsym routine.

The files contained in this directory have the following significance:

• libDSOauth.a - contains one routine, dsoAuth(), which determines the starting vaddr of /usr/lib/libc.so and its size.

• DSOauth.c is the source used to build the libDSOauth.a library.

• subversion.c is used to create its accompanying object file which this is compiled into a DSO, libsubversion.so. This source shows the basic way in which you can replace an existing DSO function with one of your own. The DSO library that is produced from this code can be added to any DSO-based application through the use of the _RLD_LIST environment variable (as shown in the script called subversion). This allows functions to replace the same named functions within the applications standard DSO list.

• smartapp.c is compiled with libDSOauth into the smartapp binary and uses the returned info to compare with the addr of dlsym to determine if it is being replaced.

• subversion - a script which through the use of the _RLD_LIST variable allows a library (libsubversion.so) to be attached to the app to replace a DSO library function.

• Makefile indicates how the different TARGETS are compiled.